home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000125_news@newsmaster….columbia.edu _Mon May 25 09:39:39 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  6KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA16536
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 25 May 1998 09:39:38 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA16216
  7.     for kermit.misc@watsun; Mon, 25 May 1998 09:39:37 -0400 (EDT)
  8. Path: news.columbia.edu!newsfeed.nyu.edu!feeder.qis.net!news-peer.gip.net!news-penn.gip.net!news.gsl.net!gip.net!news.belnet.be!news.rediris.es!newsfeed.mad.ibernet.es!news.mad.ibernet.es!not-for-mail
  9. From: clizzard@sunnydesert.com (Diego Berge)
  10. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  11. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  12. Date: 23 May 1998 10:39:44 GMT
  13. Organization: Telefonica Transmision de Datos
  14. Lines: 24
  15. Message-ID: <6k691g$bn3$2@talia.mad.ibernet.es>
  16. References: <35646665.EBB3868B@theriver.com> <wkvhqye9g4.fsf@jhuapl.edu> <6k42pd$a3m$1@apakabar.cc.columbia.edu> <wk67iy1b8j.fsf@jhuapl.edu> <6k4ef6$g6p$1@apakabar.cc.columbia.edu> <wk4syi58y0.fsf@jhuapl.edu>
  17. NNTP-Posting-Host: ppp41.198.redestb.es
  18. Mime-Version: 1.0
  19. Content-Type: Text/Plain; charset=US-ASCII
  20. X-Newsreader: WinVN 0.99.9 (Released Version) (16bit)
  21. Xref: news.columbia.edu comp.protocols.kermit.misc:8786 comp.sys.hp48:81422
  22.  
  23. Hi,
  24.  
  25.    PFJI
  26.  
  27. In article <wk4syi58y0.fsf@jhuapl.edu>, collibf1@jhuapl.edu says...
  28. >
  29. >>   set carrier-watch off  ; (Does the HP-48 assert DCD? If so, use ON.)
  30.  
  31.    The 48 doesn't detect DCD.
  32.  
  33. >
  34. >It has no hardware flow control, if that's what you mean.
  35. >
  36. >>   set flow none          ; (or Xon/Xoff)  
  37. >
  38. >Should be none.
  39.  
  40.    It does have. You can activate Xon/Xoff flow control by editing IOPAR 
  41. manually { x x 1 1 x } to activate xon/xoff both in transmit and receive. Read 
  42. the manual, it's in there.
  43.  
  44. Regards,
  45. Diego Berge.
  46. From news@newsmaster.cc.columbia.edu  Mon May 25 12:07:19 1998
  47. Return-Path: <news@newsmaster.cc.columbia.edu>
  48. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  49.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA05698
  50.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 25 May 1998 12:07:19 -0400 (EDT)
  51. Received: (from news@localhost)
  52.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA24216
  53.     for kermit.misc@watsun; Mon, 25 May 1998 12:07:19 -0400 (EDT)
  54. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  55. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  56. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  57. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  58. Date: 25 May 1998 16:07:18 GMT
  59. Organization: Columbia University
  60. Lines: 54
  61. Message-ID: <6kc4vm$ssl$1@apakabar.cc.columbia.edu>
  62. References: <35646665.EBB3868B@theriver.com> <wk67iy1b8j.fsf@jhuapl.edu> <6k4ef6$g6p$1@apakabar.cc.columbia.edu> <wk4syi58y0.fsf@jhuapl.edu>
  63. NNTP-Posting-Host: watsun.cc.columbia.edu
  64. Xref: news.columbia.edu comp.protocols.kermit.misc:8787 comp.sys.hp48:81425
  65.  
  66. In article <wk4syi58y0.fsf@jhuapl.edu>,
  67. Skip Collins  <collibf1@jhuapl.edu> wrote:
  68. : fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  69. : > Most Kermit programs prefix all control characters by default when sending
  70. : > a file.  Kermit 95 is the exception, since most Windows 95 users demand
  71. : > "high performance".  Kermit 95's default is to unprefix a fairly safe
  72. : > subset of control characters.
  73. : 
  74. : If I had to bet on what trips up most K95-HP48 connections I would wager it
  75. : is control-char unprefixing. I will try it with mskermit when I get a
  76. : chance. What command should I issue to mimic the K95 default?
  77. : 
  78. Something like this:
  79.  
  80.   SET CONTROL UNPREFIX ALL
  81.   SET CONTROL PREFIX 0 1 13 17 19 129 141 145 147
  82.  
  83. : > : I think the physical link is transparent to control characters. But
  84. : > : perhaps the hp48 kermit software assumes prefixing.
  85. : >
  86. : > The cardinal rule of any communications protocol is "be conservative in
  87. : > what you send, be liberal in what you receive".  The HP48 has it backwards.
  88. : > There is no prohibition in the protocol definition against sending bare
  89. : > control characters, 
  90. : 
  91. : This seems to contradict "Kermit: A File Transfer Protocol", 1987 ed.,
  92. : which states on page 248, under the heading Encoding Summary: "Prefix
  93. : encoding for control characters is mandatory."
  94. : 
  95. No good deed goes unpunished.  The conservative original design of the
  96. protocol (to protect users from nontransparent connections) resulted in 
  97. so much heckling from the ZMODEM contingent that we now allow the user to
  98. specify a list of control characters that may be unprefixed.  This is,
  99. strictly speaking, in violation of the protocol definition, and as such
  100. it is not (and, as explained previously, can not be) negotiated at the
  101. protocol level.
  102.  
  103. Nevertheless, the sample code that accompanies the protocol definition
  104. (op.cit., p.231) allows for bare control characters to be received.
  105.  
  106. : As long as you are cataloguing peculiarities, the HP48 sends packet
  107. : sequence numbers that are larger than 63. One can compensate by doing
  108. : mod63 before verifying. Is this right?
  109. : 
  110. No.  Packets numbers should be 0-63, period.  The packet length field is
  111. one byte long, and contains a printable character.  Even if the receiver
  112. chopped off the high bits from an incoming packet number, this would work
  113. only up to packet 95, since the packet after that would be out of sequence.
  114. Thus if it's true that HP does not wrap packet sequence numbers from 63 to
  115. 0, then it would appear that it could never, under any circumstances, send
  116. files or objects that do not fit into 64 or 96 packets, depending on how 
  117. the Kermit receiver is coded.
  118.  
  119. - Frank